In the current implementation of a pool of core network control entities, all members of a pool are identified by an indicator that has the same bit-length for all members of the same pool of a certain type. Additionally, in most presently used pool implementations (with a very few amount of pools of a certain type deployed on country level), the node identifier must be also unique on country-level.
The indicator used in the MME (Mobility Management entity) pool implementation has a fix length of 8 bits and it represents the MME Code and it is separated from the TMSI (Temporary Mobile Subscriber Identity) field which is 32-bits long, they are forming together the SAE (System Architecture Evolution)-TMSI (S-TMSI) which is part of GUTI (Globally Unique Temporary ID), while for the SGSN (Serving GPRS Support Node) and MSC (Mobile Switching Center) pool, a special node identification field (the Node Resource Identifier, NRI) is part of the TMSI field and, according with the current standards, has a fixed length for all Core networks control entities that are part of the same pool and cannot be changed during normal pool operation without major traffic disturbances of the registered mobile users. The NRI shall have a unique value within a pool (or even within a network in case there are not enough pools deployed or the operator does not want to risk reusing the NRIs in non-adjacent pools). The TMSI length in the SGSN and MSC-Server is 32-bits long (as specified in 3GPP TS 23.003).
Telecommunication networks are evolving and growing; geographical redundancy, equally distributed traffic on all core network control entities, fast network expansion procedure, shorter time to market for new features and network capacity expansions are some of the main aspects in a modern mobile communication network, independently if we talk about a 4G LTE (Long Term Evolution) network (MME as a core network control entity), a 2G or 3G PS (packet switched) network (SGSN as a core network control entity) or a 2G or 3G CS network (MSC-S as a core network control entity), or any future communication network. A common answer to all these aspects is offered by the pooling mechanisms used in the core networks and by deploying pools of all types of core network control entities (for example MME, SGSN and MSC-S).
The current 3GPP standards are limiting the expansion and flexibility capabilities of core network pools, the node identifier used to help the radio network control entities to route the UE (user equipment) traffic to the proper core network control entity is either limited to a single and fixed length (8-bits can be used to identify an MME member of a pool) or, even when different bit-lengths are possible, only one length can be used for all pool deployments of a certain type (for SGSN and MSC pools). Changing of the length of the identifier is usually a complex and risky process that might imply complete removal of the pool definitions in the complete network, activity that cannot be performed without traffic impacts.
Since the S-TMSI structure for LTE comprises an 8-bit fixed length used for the MME Code (equivalent to the NRI used in SGSN and MSC-S pools), the limitation is not as critical as 2G or 3G, since it still allows a 32-bit TMSI field—the combinations of the two allows in LTE a higher capacity and potential number of MME nodes in a network with lower risk of hitting any limitation on both of the two fields compared to 2G or 3G).
On the other hand, using a similar logic as for LTE on the SGSN or MSC-S P (Preliminary)-TMSI or TMSI a fixed length NRI of 8 bits would limit significantly the capacity of a node or limit the amount of nodes that can be deployed in a network: In general when the number of bits provided for the length of the NRI increases, the number of available bits for the TMSI is decreased. This also means that less subscribers can be stored in the Visited Location register (VLR) for one NRI value if the length of the NRI is big, and less VLRs can be located in the pool for one NRI value if the length of the NRI is short.
Even if 3GPP TS 23.236 presents the possibility to reuse NRIs in non-adjacent pools, the known implementations have shown that this is an unwanted practice due to the risk that for subscribers which travel between two pools that are sharing the same NRI numbers, the radio network part cannot recognize that this is a new subscriber in the pool (new subscriber meaning that it comes from another core network control entity in another pool) and that the subscriber should be distributed to a core network control entity of the new pool according with the core network control entities capacity factors defined for the registration procedure in the radio network and, subsequently, get a new NRI related to the selected core network control entity. This behavior creates unbalancing between the core network control entity members of the new pool, since the capacity provided by each member of the pool is not taken into account.
In order to avoid multiple UEs having the same NRI and TMSI within the same pool it is also recommended that operators are keeping a low amount of pools deployed in one network and that the NRIs shall be uniquely allocated on network level for all pools of the same type. Furthermore, due to the fact that the NRI has a fixed length, the maximum number of nodes of a certain type that can be pooled in one network is limited to the selected bit-length of the NRI.
The need to expand the pool with additional nodes or increase nodes' capacity (when all NRIs have been used) might lead to major problems: in order to be able to further expand the pool, the NRI length needs to be expanded, new and current NRIs needs to be allocated, TMSI reallocation for all subscribers and subscriber redistribution in the pool have to be ordered. In the current implementation, such action cannot be done without major traffic disturbance: the pool has to be redefined, nodes get new NRIs with a different length, distribution tables in the radio controllers change and, the worse, traffic disturbances (e.g. MO (Mobile Originating) transaction failures), increased signaling load to the HLRs (Home Location Registers), massive subscriber redistributions, increased paging failure and of the amount of global paging attempts), and all UEs will need to receive new TMSIs.
With the introduction of blade-specific architectures and virtualization of the core network control entities, the above-listed issues will become even more obvious and additional limitations might appear—e.g. due to the need to adapt the cloud network architecture on the fly, based on current traffic needs, additional capacity of NFVs (Network Function Virtualization) have to be added or removed from a pool at any moment of time without any traffic disturbances.
Furthermore when pools of core network control entities are used, these entities may have different capacities. As the NRI length is fixed for all the members of the pool, then the core network control entity with the high capacity has the same number of TMSIs available compared to a core network control entity with a lower capacity due to the fixed length. Thus the core network control entity with the high capacity can not allocate more TMSIs than the core network control entity with the low capacity, even though it would have the capacity to do so.